Use more idiomatic angular when parsing opts, and add a provider to allow setting of defaults #55
Conversation
…h will be used in any corresponding angular hm-X invocation (except custom), as well as import defaults from Hammer's own presets object.
…pts to array to avoid code duplication, 2. apply directive defaults properly if not hmCUstom, 3. rewrite how extending works to handle extending/applying defaults.
…zer opts to be used. unsure about how hammer applies defaults if empty recognizer opts supplied but this seems to be fine (ie defaults used if no overriding params)
…break if hammer included through other means and browserify is used, 2. simplify a bunch of code including event handler which doesn't need to check digest phase, 3. fix a bunch of bugs with the previous iteration, 4. allow options to target doubletap specifically using eventname, 5. better normalization so less code in link function
|
I'm going to need to make some small changes to authorship and such before publishing this. Going to make a contributor list and change the copyright to be the group of us. Thanks for taking the time to do pretty much everything I wanted to do 6 months ago but haven't had time for. |
Use more idiomatic angular when parsing opts, and add a provider to allow setting of defaults
|
The |
|
I will do this eventually, but I haven't been working on touch stuff much recently and therefore haven't had a chance to test it. If you find that this is pretty stable then I will tag a release and push to NPM and Bower. |
|
I use this at work quite a lot with multiple hammer events (and others) soetimes attached to single elements, and everything has been ok thus far, but frankly I found HammerJS a bit of a pain working with - it doesnt feel very developer friendly for this sort of thing - and so I wouldn't be surprised if there were edge cases specifically regarding passing options through and using custom events. One thing I noticed, iirc, is that click duration is ignored when you combine a hm-tap with a hm-pan. I believe the issue was with hammer rather than this plugin but didn't take the investigation very far as it wasn't too important at work. |
|
Well that last bit is fascinating. I will say that last I heard Hammer.js was going on the original author's back burner. Not sure what the current status is though, maybe someone took over. |
|
@RyanMullins I haven't found any issues till now. But, a new issue has popped up for iOS 9. I have opened a separate issue for that (hammerjs/hammerjs.github.io#28). But I guess for now you can published the above mentioned changes to |
This should be fixed by the patch release we're working on. There was a leaky config issue, the buggy behavior of which apparently most of our tests relied upon. |
We haven't begun looking at iOS9 yet, but if there is actually an iOS9 specific issue I'll take a gander it's related to the new force-touch API. |
The provider allows default options to be set globally, along with an option to import Hammer's own presets if you defined them there. It merges those options in to any provided where appropriate.
In addition I strip down code duplication by normalizing opts to an array, takingcare (hopefully correctly!) to cater for custo mdirective and applying defaults eg doubletap.
Nice work! I hope this helps a little.